Google Cloud：プロジェクトの組織間移行について解説

Google Cloud 組織間のプロジェクト移行

Google Cloud (旧GCP)のプロジェクト移行は、組織の成長や再構成、または管理の煩雑さを軽減するために行うことがあります。
プロジェクトの移行は、Resource Manager APIを利用することでスムーズに行うことができます。

今回は、公式のホームページの情報をもとに、GCP組織間のプロジェクト移行の方法とその注意点について解説していきます。

組織間のプロジェクト移行とは

先にお伝えした、Resource Manager APIとは、Google Cloudの全リソースを管理するためのAPIになります。
さらに、移行が上手くいかなかった場合や元の構成に戻したい場合などには、ロールバックと呼ばれる工程をResource Manager APIを使用して行うことで、プロジェクトをリソース階層内の元の場所に戻すことが可能です。

移行後の権限について

プロジェクトレベルで設定されたIAMの割り当ては移行時に変わりません。
つまり、もし移行後も適切なポリシーが適用されていることを確認したい場合には、移行前にプロジェクトに直接ポリシーを適用しておくことが最適です。

一方、組織リソースレベル（移行前組織）で定義された割り当ては移行により失われます。（組織ポリシーは引き継がれない）
そして、移行することによりプロジェクトは元のリソース階層からのポリシーの継承を失い、移行先で有効なポリシーが適用されるようになります。

これは、移行前に移行先の有効なポリシーが、元のプロジェクトのポリシーと一致するよう確認しておくべき理由にもなります。

プロジェクト移行前の分析

プロジェクトの移行は、単純に実行すれば良いというものではなく、計画的に行う必要があります。
Cloud Asset Inventory Analyze Move APIを使用すれば、プロジェクトを実際に移動する前に、重要なポリシーシステムのリストから警告と障害に関する詳細なレポートを取得できるのです。

要するに、プロジェクトを移行する前にエラーが出る箇所を事前に特定してくれる仕組みです。

分析の実行

例えば次のようなコマンドでプロジェクトを別の組織に移動した場合の影響を分析できます。

※ プロジェクトを別の組織に移動した場合の影響を分析するには、--destination-organizationを使用してコマンドを実行します。

コマンド実行後には、移行に伴う各サービスごとの警告とブロッカー（移行の障害となりうる要素）のリストが表示されます。
これらの警告とブロッカーを解決してからプロジェクトの移行を始めることで、予期せぬ問題を避けることができます。

下記の公式ホームページから実行時の詳細もご確認いただけます。

• 分析を実行する
• https://cloud.google.com/resource-manager/docs/analyze-move?hl=ja#perform_the_analysis

分析時のエラー

もしも分析時に移行の評価に失敗すると、そのままでは組織間移行がうまくいかないことを示唆しています。
それぞれのエラーを可決してから、再度gcloudコマンドやAPIから組織を移行を実行する必要があります。

エラー解決の詳細などは下記の公式ホームページから確認ください。

• 分析のレスポンスを移動する
• https://cloud.google.com/resource-manager/docs/analyze-move?hl=ja#move_analysis_responses
• エラーのトラブルシューティング
• https://cloud.google.com/resource-manager/docs/analyze-move?hl=ja#troubleshooting_errors

移動分析時に必要な権限

　ただ、上記の分析操作を実行するための権限も必要になるため下記の公式ホームページから確認ください。

• 権限の割り当て
• https://cloud.google.com/resource-manager/docs/analyze-move?hl=ja#assign_permissions

プロジェクト移動分析を実行するには、cloudasset.assets.analyzeMove 権限（Cloud Asset 閲覧者や閲覧者など）を付与するロールが必要です。

移行時のポイント

実際の移行に必要な権限

分析ではなく、実際に移行を行うとなった場合にも専用の権限が必要です。
例えば、今回は他組織間でのプロジェクトの移行のため、移行元と移行先、両方に下記のような権限があることを確認する必要があります。

• 移行元の組織の権限
• プロジェクトIAM管理者（`roles/resourcemanager.projectIamAdmin`）
• プロジェクト移動(roles/resourcemanager.projectMover)
• 移行先の組織の権限
• プロジェクトIAM管理者（`roles/resourcemanager.projectIamAdmin`）（任意）
• プロジェクト作成者（`roles/resourcemanager.projectCreator`）
• プロジェクト移動(roles/resourcemanager.projectMover)

※ なお、直接的には関係はありませんが、組織ポリシーを作成&管理する権限である(roles/orgpolicy.policyAdmin)については、組織ポリシーを変更する場合にのみ必要となる場合があります。

移行元/移行先の組織ポリシー

プロジェクトの組織間移行を行う場合には、両組織でポリシーの設定を行う必要があります。

プロジェクトのエクスポートを含む組織のポリシーとインポートを許可する組織ポリシーを移行先に設定します。

ただし、予期せぬエラーなどに備えて両組織にポリシーを設定することをお勧めします。

• 移行元の組織の権限
• constraints/resourcemanager.allowedExportDestinations制約
• constraints/resourcemanager.allowedImportSources制約
• 移行先の組織の権限
• constraints/resourcemanager.allowedImportSources制約
• constraints/resourcemanager.allowedExportDestinations制約

結局、移行元と移行先の両方に受け入れを許可する組織ポリシーを設定することが必要になります。

そして、移行完了後はこのポリシーを削除することが推奨させています。

注意: 上記に記した組織のポリシーを設定していない場合、移行により FAILED_PRECONDITION エラーが発生します。

課金について

プロジェクトをある組織リソースから別の組織リソースに移行しても課金に影響はありません。
料金は、古い請求先アカウントに対して継続して課せられます。

ただし、組織リソース間でプロジェクトを移行する場合は、ポリシーなどにより新しい請求先アカウントへの移行要件があることもあります。

まとめ

組織間のプロジェクト移行は計画的に、そして慎重に行うべきです。
Cloud Asset Inventory Analyze Move APIを用いて移行前の影響分析を行ったり、移行後のポリシーの適用状況に注意を払うことで、スムーズな移行が可能になります。

移行の過程で何か問題が生じた場合でも、Resource Manager APIを用いてロールバックすることで初期の状態に戻すことも出来ます。
移行時はしっかりとした計画と適切な組織ポリシーの設定により、さらに進化したcloud環境へと進める重要なステップになります。